-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Angular from visualize #20295
Conversation
723fe1b
to
71e3704
Compare
71e3704
to
c0ccec2
Compare
💔 Build Failed |
8d1192c
to
457345d
Compare
💔 Build Failed |
0ce3f31
to
3bc7801
Compare
💔 Build Failed |
b304555
to
266bae8
Compare
💔 Build Failed |
266bae8
to
9624da8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Tested on chrome/osx.
Just a minor comment
this._listeners = new EventEmitter(); | ||
// Listen to the first RENDER_COMPLETE_EVENT to resolve this promise | ||
this._firstRenderComplete = new Promise(resolve => { | ||
this._listeners.once(RENDER_COMPLETE_EVENT, resolve); | ||
}); | ||
this._element.on('renderComplete', () => { | ||
this._element.addEventListener('renderComplete', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems that we are not removing the event listener of this renderComplete
event in the destroy. Is it fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree, I think we should deregister this properly.
src/ui/public/visualize/index.js
Outdated
@@ -17,4 +17,4 @@ | |||
* under the License. | |||
*/ | |||
|
|||
import './visualize'; | |||
import './loader'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't make much sense, since loader itself just exports some classes. We should either put an export * from './loader';
here in case we want to enable importing getVisualizeLoader
from ui/visualize
directly, or just remove the whole index.js
file.
this._listeners.emit(RENDER_COMPLETE_EVENT); | ||
}); | ||
|
||
this._loaded = false; | ||
this._destroyed = false; |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
}); | ||
}; | ||
|
||
_fetchAndRender = _.debounce((forceFetch) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Give this a default value = false
for better readability.
@@ -17,7 +17,11 @@ | |||
* under the License. | |||
*/ | |||
|
|||
import _ from 'lodash'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should rather start using named imports for that (since it would potentially allow for better tree shaking - and imho also improves readability): import { debounce } from 'lodash';
} | ||
|
||
/** | ||
* Destroy the underlying Angular scope of the visualization. This should be | ||
* called whenever you remove the visualization. | ||
*/ | ||
destroy() { | ||
this._scope.$destroy(); | ||
this._destroyed = true; | ||
this._vis.removeListener('reload', this._reloadVis); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there might be a tiny chance, that we're actually currently have triggered a fetchAndRender
that's still in debounce while we're destroying. I think in that case we should cancel the debounce. It seems the method returned from the debounce
call above should have a property cancel
so that we can call this._fetchAndRender.cancel()
here.
* specific language governing permissions and limitations | ||
* under the License. | ||
*/ | ||
import _ from 'lodash'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, could we use named imports, please.
|
||
const handlerParams = { | ||
...props, | ||
forceFetch: forceFetch, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎨 Just forceFetch
would be enough.
this._previousVisState = this._vis.getState(); | ||
this._previousRequestHandlerResponse = requestHandlerResponse; | ||
|
||
this._visData = canSkipResponseHandler ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎨 I would prefer the following version slightly:
if (!canSkipResponseHandler) {
this._visData = await Promise.resolve(this._responseHandler(this._vis, requestHandlerResponse));
}
💚 Build Succeeded |
this._responseHandler = getHandler(responseHandlers, responseHandler); | ||
} | ||
|
||
fetch = async (props, forceFetch = false) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that can use the regular function syntax async fetch(props, forceFetch = false) {
since we don't seem to call this anywhere in a weird this
-overwriting way.
this.props.searchSource.cancelQueued(); | ||
this._vis.requestError = e; | ||
if (isTermSizeZeroError(e)) { | ||
return toastNotifications.addDanger( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should really move this to a more sane place (though not necessarily in this PR, but we should start thinking about what a sane place could be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks now good for me. Tested it out (Chrome, Linux) with different combinations of visualizations/dashboards/etc couldn't find any issue.
LGTM, as long as it's merged after #20480 has been reviewed, merged, and this one rebased on it.
💔 Build Failed |
f236803
to
b24c043
Compare
💔 Build Failed |
b24c043
to
3a76eb6
Compare
💚 Build Succeeded |
Just a note that this PR apparently broke auto refresh on visualizations and dashboards. |
removes angular from visualize directive and turns it into a class.
From now on the data fetching (that was earlier part of the
<visualize>
directive) will be triggered by the visualize loader directly, which then renders or updates theVisualization
React component with the fetched data.This PR removes Angular completely from out central rendering infrastructure 🎉